In Unconditional ACL, ACL evaluation is done based on the metadata of the object. The request prepared is sent to the ACL engine for evaluation and based on that, the data retrieval and updating is done.

As mentioned above, ACL is set on the metadata of an object. ACL can be one of the following:

• open
• blocked
  
  By default, all permissions are open. Below is a sample ACL object tree, which blocks the GetEmployee Web service operation in Web service interface Northwind in the Northwind Service Group.

  <object id="cn=NorthwindService,cn=soapnodes,o=system,cn=cordys,o=vanenburg.com">
      <object id="http://schemas.cordys.com/1.0/demo/northwind">
          <object acl="blocked" id="GetEmployee"/>
      </object>
  </object>
  

  
  Note: Usually when specifying the ACL settings for an object, the cn or dn of the object would be specified. But in the case of a Web service interface, the namespace of the Web service interface is specified while setting the ACL. For example, to set ACL for Web service interface Northwind, the namespace http://schemas.cordys.com/1.0/demo/northwind is used inside the object settings, instead of the name of the Web service interface.

  
  Important: For an anonymous user to access database related methods, ACLs must be set at the database or the table level. Following is an example of how database level permissions are set for an object:

  <object id="cN=Oledb,cn=soap nodes,o=system,cn=cordys,o=vanenburg.com">
    <object id="testdb">
      <object id="testtablename">
        <method id="read" acl="open" />
      </object>
    </object>
    <object id="http://schemas.cordys.com/oledbkaltest" acl="open">
      <object id="GetkaltestObject" acl="open" />
    </object>
  </object>
  //Where testdb is the database name and testtable name is name of the table in the database//

  
  ACL Settings at Metadata Services level can be set at the object level or at the Web service operation level. When set at object level, the hierarchy of permissions are open or blocked. Every child object inherits the settings from its parent object, unless specified otherwise. Below is an example of an ACL setting for a parent object and its child:

  <object acl="blocked" id="parentObject">
      <object id="childObject"/>
      <object acl="open" id="childObject2"/>
  </object>
  

  
  In the above code snippet, the permission for the childObject is set as blocked as nothing is specified on this child object. But for childObject2, the permission is set as open.
  
  When set at Web service operation level, the permissions are hierarchical in the following order:

• read
• update
• insert
• delete
  
  Following is an example of how Web service operation level permissions are set for an object:

  <object id="parentObject">
      <object id="childObject1">
          <method acl="open" id="delete"/>
      </object>
      <object id="childObject2">
          <method acl="blocked" id="insert"/>
      </object>
  </object>
  

  
  The above object tree indicates that the ALL permissions are open on childObject1, since delete is open. For childObject2, the insert permissions are blocked, and as per the hierarchy, insert and delete permissions are blocked. When read permission is blocked for a user, then the user is completely blocked from accessing the object. ACL settings are strictly hierarchical in nature, and hence when multiple Web service operation settings are set for an object, the object with the highest priority (topmost hierarchy) is considered as the setting.
  
  Note: When an update operation is tried on a field that is blocked, the result would be an empty tag for that field, implying that it is not possible to update that field.
  ACL settings can be defined for System Administrators, who are authorized to administer the entire Cordys System, and Organizational Administrators, who administer an organization in Process Platform.
  
  Roles can be defined within an organization as well as at the system level. Organizational roles are defined within an organization, and can be assigned to the users within an organization. A user in an organization must be assigned at least one role. The roles can have sub roles and the sub roles can again contain roles under them and so on. ACL settings can be specified on organizational roles that belong to a particular organization.